CodePipeline, CodeBuildを使ってAmazon ECSへの継続的デプロイメントを試してみた

モバイルアプリサービス部の五十嵐です。

Amazon Web Services ブログのエントリー「AWS CodePipeline, AWS CodeBuild, Amazon ECR, AWS CloudFormationを利用したAmazon ECSへの継続的デプロイメント」 で紹介されているリファレンスアーキテクチャを実際に手組で構築してみたりサンプルで動きを確認してみましたので、ブログの補足的な位置づけとして、より詳細な動きを解説してみます。

前提知識

ECS/ECR、CodeBuild、CodePipeline、CloudFormation などのサービスの基礎知識が必要となります。

アーキテクチャ

紹介されているリファレンスアーキテクチャを以下に示します。

引用: Amazon Web Services ブログ

1. 開発者がGitRepositoryにソースコードをPushします。
2. CodePipelineがGitRepositoryをポーリングして変化があるとプロセスが開始されます。
3. CodeBuildがGitRepositoryからソースコードを取得します。
4. CodeBuildがソースコードからDockerImageをビルドしてECRに登録します。
5. CloudFormationがUpdateStackされます。
6. ECSのTaskDifinitionの新しいリビジョンが作成されます。
7. ECSがECRから最新のイメージを取得してアプリケーションを更新します。

CodePipeline

次にCodePipelineの動きに注目してみます。CodePipelineを使いこなすには、サービス間の Input と Output でそれぞれ何が受け渡されているかを把握することが重要になります。それを可視化したのが以下の図です。

CodeBuildの buildspec.yml の中で、新しいTagバージョンを生成し、それを新しいDockerImageのTagとして登録し、CloudFormationでもそのTagをパラメータとして受け取り、TaskDifinitionを更新する（新しいリビジョンを作る）という動作になっていました。（Tagの値が変わらなければ、TaskDifinitionのリビジョンは変わらないようでした。）

課題

• CodePipelineのトリガーは、現在はメインブランチへのコミットのみですが、より細かく制御できるようにしたいです。
• CodePipelineで統合できる各種サービスはCodePipelineと同じリージョンにある必要がありますが、CodeBuildは東京リージョンにまだ無いため、CloudFormationもそれに引きずられる形になります。（CodeBuildの東京リージョン対応が待たれます。）

まとめ

ECSへの継続的デプロイメントの1つの方法が示されました。Amazon Web Services ブログで紹介されているサンプルを使えば様々なサービスに応用ができると思います。ぜひお試しください。

おまけ

参考までに、私が手組で構築してみたサンプルプロジェクトは以下に公開しています。

• cm-igarashi-ryosuke/sample_ecs_service: ECSのデプロイ自動化に向けた検証アプリ